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Abstract 


This document describes methods for handling Unicode strings 
representing memorable, human-friendly names (called "nicknames", 
"display names", or "petnames") for people, devices, accounts, 
websites, and other entities. This document obsoletes RFC 7700. 
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received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 
Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www. rfc-editor.org/info/rfc8266. 
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ONONUOWDHNDAUUARHRWNN 


A number of technologies and applications provide the ability for a 
person to choose a memorable, human-friendly name in a communications 
context or to set such a name for another entity such as a device, 


account, contact, or website. 
"nicknames" (e.g., in chat room applications), 
in Internet mail), or "petnames" (see [PETNAME-SYSTEMS] ); 
consistency, these are all called 


"nicknames" 


Such names are variously called 
"display names" (e.g., 


for 


in this document. 


Nicknames are commonly supported in technologies for textual chat 
rooms, such as: 


(0) 


o The Message Session Relay Protocol (MSRP) [RFC4975] 


(0) 


o The Extensible Messaging and Presence Protocol (XMPP) 


Saint-Andre 


Internet Relay Chat (IRC) [RFC2811] 


Centralized Conferencing (XCON) [RFC5239] 


[XEP-0045] 


Standards Track 


[RFC7701] 
[XCON-SYSTEM] 


[RFC6120] 
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Recent chat room technologies also allow internationalized nicknames 
because they support code points from outside the ASCII range 
[RFC20], typically by means of the Unicode coded character set 
[Unicode]. Although such nicknames tend to be used primarily for 
display purposes, they are sometimes used for programmatic purposes 
as well (e.g., kicking users out of a chat room or avoiding nickname 
conflicts). 


A similar usage enables a person to set their own preferred display 
name or to set a preferred display name for another user (e.g., the 
"display-name" construct in the Internet message format [RFC5322] and 
the <nick/> element in XMPP [XEP-0172]). 


Memorable, human-friendly names are also used in contexts other than 
personal messaging, such as names for devices (e.g., in a network 
visualization application), websites (e.g., for bookmarks in a web 
browser), accounts (e.g., in a web interface for a list of payees in 
a bank account), people (e.g., in a contact list application), and 
the like. 


The rules specified in this document can be applied in all of the 
foregoing contexts. 


It is important to understand that a nickname is a personally 
memorable name or handle for something that has a more stable, 
underlying identity, such as a URI or a file path. To ensure secure 
operation of applications that use nicknames, authentication and 
authorization decisions MUST be made on the basis of the thing's 
identity, not its nickname. 


To increase the likelihood that memorable, human-friendly names will 
work in ways that make sense for typical users throughout the world, 
this document defines rules for handling nicknames in terms of the 
preparation, enforcement, and comparison of internationalized strings 
(PRECIS) framework specification [RFC8264]. 


1.2. Terminology 


Many important terms used in this document are defined in [RFC8264], 
[RFC6365], and [Unicode]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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2. 
2.1. 


Nickname Profile 


Rules 


The following rules apply within the Nickname profile of the PRECIS 
FreeformClass defined in the PRECIS framework specification 
[RFC8264]. 


1. 


Width Mapping Rule: There is no width mapping rule (such a rule 
is not necessary because width mapping is performed as part of 
normalization using Normalization Form KC (NFKC) as specified 
below). 


Additional Mapping Rule: The additional mapping rule consists of 
the following sub-rules. 


a. Map any instances of non-ASCII space to SPACE (U+0020); a 
non-ASCII space is any Unicode code point having a general 
category of "Zs", naturally with the exception of SPACE 
(U+@020). (The inclusion of only ASCII space prevents 
confusion with various non-ASCII space code points, many of 
which are difficult to reproduce across different input 
methods. ) 


b. Remove any instances of the ASCII space character at the 
beginning or end of a nickname (e.g., "Stpeter " is mapped to 
"stpeter"). 


c. Map interior sequences of more than one ASCII space character 
to a single ASCII space character (e.g., "St Peter" is 
mapped to "St Peter"). 


Case Mapping Rule: Apply the Unicode toLowerCase() operation, as 
defined in the Unicode Standard [Unicode]. In applications that 
prohibit conflicting nicknames, this rule helps to reduce the 
possibility of confusion by ensuring that nicknames differing 
only by case (e.g., "“Stpeter" vs. "StPeter') would not be 
presented to a human user at the same time. (As explained below, 
this is typically appropriate only for comparison, not for 
enforcement. ) 


Normalization Rule: Apply Unicode Normalization Form KC. Because 
NFKC is more "aggressive" in finding matches than other 
normalization forms (in the terminology of Unicode, it performs 
both canonical and compatibility decomposition before recomposing 
code points), this rule helps to reduce the possibility of 
confusion by increasing the number of code points that would 
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match; for example, the character "IV" (ROMAN NUMERAL FOUR, 
U+2163) would match the combination of "I" (LATIN CAPITAL LETTER 
I, U+0049) and "V" (LATIN CAPITAL LETTER V, U+0056). 


5. Directionality Rule: There is no directionality rule. The "Bidi 
Rule" (defined in [RFC5893]) and similar rules are unnecessary 
and inapplicable to nicknames, because it is perfectly acceptable 
for a given nickname to be presented differently in different 
layout systems (e.g., a user interface that is configured to 
handle primarily a right-to-left script versus an interface that 
is configured to handle primarily a left-to-right script), as 
long as the presentation is consistent in any given layout 
system. 


Implementation experience has shown that applying the rules for the 
Nickname profile is not an idempotent procedure for all code points. 
Therefore, an implementation SHOULD apply the rules repeatedly until 
the output string is stable; if the output string does not stabilize 
after reapplying the rules three (3) additional times after the first 
application, the implementation SHOULD terminate application of the 
rules and reject the input string as invalid. 


2.2. Preparation 


An entity that prepares an input string for subsequent enforcement 
according to this profile MUST ensure that the string consists only 
of Unicode code points that conform to the FreeformClass string class 
defined in [RFC8264]. 


2.3. Enforcement 


An entity that performs enforcement according to this profile MUST 
prepare an input string as described in Section 2.2 and MUST also 
apply the following rules specified in Section 2.1 in the order 
shown: 


1. Additional Mapping Rule 
2. Normalization Rule 


Note: An entity SHOULD apply the Case Mapping Rule only during 
comparison. 


After all of the foregoing rules have been enforced, the entity MUST 
ensure that the nickname is not zero bytes in length (this is done 
after enforcing the rules to prevent applications from mistakenly 
omitting a nickname entirely, because when internationalized strings 
are accepted a non-empty sequence of characters can result in a zero- 
length nickname after canonicalization). 
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The result of the foregoing operations is an output string that 
conforms to the Nickname profile. Until an implementation produces 
such an output string, it MUST NOT treat the string as conforming (in 
particular, it MUST NOT assume that an input string is conforming 
before the enforcement operation has been completed). 


2.4. Comparison 


An entity that performs comparison of two strings according to this 
profile MUST prepare each input string as specified in Section 2.2 
and MUST apply the following rules specified in Section 2.1 in the 
order shown: 


1. Additional Mapping Rule 
2. Case Mapping Rule 
3. Normalization Rule 


The two strings are to be considered equivalent if and only if they 
are an exact octet-for-octet match (sometimes called "bit-string 
identity"). 


Until an implementation determines whether two strings are to be 
considered equivalent, it MUST NOT treat them as equivalent (in 
particular, it MUST NOT assume that two input strings are equivalent 
before the comparison operation has been completed). 


3. Examples 


The following examples illustrate a small number of nicknames that 
are consistent with the format defined above, along with the output 
string resulting from application of the PRECIS rules for comparison 
purposes (note that the characters "<" and ">" are used to delineate 
the actual nickname and are not part of the nickname strings). 
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[So [es + 
| # | Nickname | Output for Comparison | 
Poona Pp MtMMtMtMtMtMtMtMtMiM$M + 
| 1 | <Foo> | <foo> | 
+----------------- ------- = $--- + 
| 2 | <foo> | <foo> | 
+- +=- MtaMttMtMtMtMtMtMtMtiMi + 
| 3 | <Foo Bar> | <foo bar> | 
+--------------- -- -- = +--- + 
| 4 | <foo bar> | <foo bar> | 
+- Of + 
|5 | E> | o (GREEK SMALL LETTER SIGMA, l 
l l | U+03C3) | 
[Pe poaa a5 55-55 5 5 + 
| 6 | <o> | o (GREEK SMALL LETTER SIGMA, l 
l l | U+03C3) | 
[ee [ee iMtMMtMtMtMtMtMiMtM + 
| 7 | <ç> | ¢ (GREEK SMALL LETTER FINAL SIGMA, | 
| | | U+@3C2) | 
fan J ea iMtMMtMtMtMtMtMiMtM + 
| 8 | <> | ü (GREEK SMALL LETTER UPSILON l 
| | | WITH DIALYTIKA, U+03CB) | 
Pe 4$--------------------- ------ == -- = + 
| 9 | <co> | © (INFINITY, U+221E) | 
Pee ne poaa-- 5-5-5 5-5-5 5 + 
| 10 | <Richard IV> | <richard iv> | 
[ee ee J So MiMtMtMtMtMtMiMtMiMiM + 


Table 1: A Sample of Legal Nicknames 


Regarding examples 5, 6, and 7: applying the Unicode toLowerCase() 
operation to the character "Z" (GREEK CAPITAL LETTER SIGMA, U+@3A3) 
results in the character "o" (GREEK SMALL LETTER SIGMA, U+@3C3); 
however, the toLowerCase() operation does not modify the character 
"ç" (GREEK SMALL LETTER FINAL SIGMA, U+03C2). Therefore, the 
comparison operation defined in Section 2.4 would result in matching 
of the nicknames in examples 5 and 6 but not the nicknames in 
examples 5 and 7 or 6 and 7. 


Regarding example 8: this is an instance where applying the rules for 
the Nickname profile is not an idempotent procedure (see 
Section 2.1). In particular: 


1. Applying toLowerCase() to the character "Y" (GREEK UPSILON WITH 
DIARESIS AND HOOK SYMBOL, U+@3D4) results in no changes, and 
applying NFKC to that character results in the character "Y" 
(GREEK CAPITAL LETTER UPSILON WITH DIALYTIKA, U+03AB). 
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2. Applying toLowerCase() to "Y" (GREEK CAPITAL LETTER UPSILON WITH 
DIALYTIKA, U+@3AB) results in the character "ü" (GREEK SMALL 
LETTER UPSILON WITH DIALYTIKA, U+@3CB), and applying NFKC to that 
character results in no changes. 


Regarding example 9: symbol characters such as "œ" (INFINITY, U+221E) 
are allowed by the PRECIS FreeformClass and thus can be used in 
nicknames. 


Regarding example 10: applying the Unicode toLowerCase() operation to 
the character "IV" (ROMAN NUMERAL FOUR, U+2163) results in the 
character "iv" (SMALL ROMAN NUMERAL FOUR, U+2173), and applying NFKC 
to the character "iv" (SMALL ROMAN NUMERAL FOUR, U+2173) results in 
the characters "i" (LATIN SMALL LETTER I, U+0069) and "v" (LATIN 
SMALL LETTER V, U+0Q76). 


4. Use in Application Protocols 


This specification defines only the PRECIS—based rules for handling 
of nickname strings. It is the responsibility of an application 
protocol (e.g., MSRP, XCON, or XMPP) or application definition to 
specify the protocol slots in which nickname strings can appear, the 
entities that are expected to enforce the rules governing nickname 
strings, and the point during protocol processing or interface 
handling when the rules need to be enforced. See Section 6 of 
[RFC8264] for guidelines about using PRECIS profiles in applications. 


Above and beyond the PRECIS-based rules specified here, application 
protocols can also define application-specific rules governing 
nickname strings (rules regarding the minimum or maximum length of 
nicknames, further restrictions on allowable code points or character 
ranges, safeguards to mitigate the effects of visually similar 
characters, etc.). 


Naturally, application protocols can also specify rules governing the 
actual use of nicknames in applications (reserved nicknames, 
authorization requirements for using nicknames, whether certain 
nicknames can be prohibited, handling of duplicates, the relationship 
between nicknames and underlying identifiers such as SIP URIs or 
Jabber IDs, etc.). 


Entities that enforce the rules specified in this document are 
encouraged to be liberal in what they accept by following this 
procedure: 


1. Where possible, map characters (e.g., through width mapping, 


additional mapping, case mapping, or normalization) and accept 
the mapped string. 
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5. 


6. 
6.1. 


2. If mapping is not possible (e.g., because a character is 
disallowed in the FreeformClass), reject the string. 


IANA Considerations 

IANA has added the following entry to the "PRECIS Profiles" registry: 

Name: Nickname. 

Base Class: FreeformClass. 

Applicability: Nicknames or display names in messaging and text 
conferencing technologies; petnames for devices, accounts, and 
people; and other uses of nicknames, display names, or petnames. 

Replaces: None. 

Width Mapping Rule: None (handled via NFKC). 

Additional Mapping Rule: Map non-ASCII space characters to SPACE 
(U+@020), strip leading and trailing space characters, and map 
interior sequences of multiple space characters to a single 
instance of SPACE (U+0020). 


Case Mapping Rule: Map uppercase and titlecase code points to 
lowercase using the Unicode toLowerCase() operation. 


Normalization Rule: NFKC. 
Directionality Rule: None. 
Enforcement: To be specified by applications. 
Specification: RFC 8266. 
Security Considerations 

Authentication and Authorization 
It is important to understand that a nickname is a personally 
memorable name or handle for something that has a more stable, 
underlying identity, such as a URI or a file path. To ensure secure 
operation of applications that use nicknames, authentication and 


authorization decisions MUST be made on the basis of the thing's 
identity, not its nickname. 
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6.2. Reuse of PRECIS 


The security considerations described in [RFC8264] apply to the 
FreeformClass string class used in this document for nicknames. 


6.3. Reuse of Unicode 


The security considerations described in [UTS39] apply to the use of 
Unicode code points in nicknames. 


6.4. Visually Similar Characters 


[RFC8264] describes some of the security considerations related to 
visually similar characters, also called "confusable characters" or 
"confusables", and provides some examples of such characters. 


Although the mapping rules defined in Section 2 of this document are 
designed, in part, to reduce the possibility of confusion about 
nicknames, this document does not provide more-—detailed 
recommendations regarding the handling of visually similar 
characters, such as those provided in [UTS39]. 
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Changes from RFC 7700 


The following changes were made from [RFC7700]. 


o Addressed [Err4570] by removing the directionality rule from 
Sections 2.3 and 2.4. 


o In accordance with working group discussions and updates to 
[RFC8264], removed the use of the Unicode toCaseFold() operation 
in favor of the Unicode toLowerCase() operation. 


o Clarified several editorial matters. 


o Updated references. 
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